Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000054_owner-urn-ietf _Thu Oct 17 17:05:35 1996.msg

Internet Message Format | 1997-02-19 | 7KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA09100 for urn-ietf-out; Thu, 17 Oct 1996 17:05:35 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA09094 for <[e-mail]>; Thu, 17 Oct 1996 17:05:32 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA28816  (mail destined for [e-mail]); Thu, 17 Oct 96 17:05:29 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id PAA22540; Thu, 17 Oct 1996 15:05:24 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 17 Oct 1996 15:12:51 -0600
To: Larry Masinter <[e-mail]>
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] a possible security architecture for URNs
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Larry Masinter (at least at 10:37 AM 10/17/96 PDT)
[And I said:]
>>         We shouldn't define an all-encompassing
>>         security policy for URNs.
>
>I agree with that. However, I had interpreted some messages (not from
>you, but from Michael and Terry) a different position, e.g., that the
>URN working group shouldn't worry about security.

Yeah, I meant to quibble a bit with Terry's message and
say that we should ensure the tools are available, but I thought
his main point was that we can't mandate the policy.
I just never got that message sent.  (Hey, I'm still working
on my reply in our off-list thread. :-)

>My primary technical concern about using DNS security for NAPTR is
>the issue of the granularity of authority. For example, it's likely
>that any authority with the ability to change ONE of the NAPTR entries
>for 'duns.urn.net' will have the ability to change all of the rest of
>the records.

I think that the entity that writes the check to have the "foo.urn.net"
namespace gets to decide what NAPTR records go there, and bears any
legal responsibility for what they do and do not put there.

>Is this the right granularity of authority?

Seems OK to me. Further, it seems isomorphic to the Rivest paper.
The owner of a naming context decides what names to put there.
If they make their naming context public, and someone doesn't
like what they have done, they can sue. Not a technical issue.

>Let's suppose that
>'duns.urn.net' has replicated resolution services around the world,
>one in the US, one in Japan, one in Australia, one in Russia:
>
>duns.urn.net
>;;      order pref flags service            replacement                regexp
> IN NAPTR 100  10  "s"  "dunslink+N2L+N2C" _dunslink._udp.isi.dandb.com ""
> IN NAPTR 100  20  "s"  "rcds+N2C"         _rcds._udp.duns.com.au    ""
> IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.dandb.co.jp    ""
> IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.duns.co.ru    ""
>
>but that the Russian operator needs to change the domain name. Or
>wants to.

Then they can communicate that desire to the owners of the duns.urn.net
domain, who will or will not honor the request, and should accept the
consequences.

{As a correction to your example, which does not change the thrust of
your question, you had a couple of entries of the form:

> IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.dandb.co.jp    ""
> IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.duns.co.ru    ""

where the same service (same resolution protocol and same resolution
services) would be available from two different domain names. We expect the
SRV record to handle that. The NAPTR would have one entry of the form

  IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.duns.com

and the SRV record for _http._tcp.duns.com would list names like
whatever.duns.co.ru and something.dandb.co.jp.  } The contents
of that SRV record are still at the discretion of whoever owns
_http._tcp.duns.com.


>Or that the Australian operator of the resolution service disputes the
>Japanese operator over the spelling of a DUNS name that is in tradmark
>dispute in the two countries.

I don't understand this example, but I still think it is the case
that if I am paying the money for a domain name, I get to say what
goes into records for that domain name, and I bear the legal
consequences for inclusion or ommision of information.

> Are you
>presuming (as is presumed with MX records for mail, which I'm assuming
>is the model for NAPTR) that the operators of the resolution services
>for a single global name space are the same commercial entity?

No, but I think we have a terminology clash.

As above, I assume there is some entity that is "responsible"
for a namespace (or at least its top level). That entity may have
contracted with some other entity (or entities) for the day-to-day
operation of resolution services. Presumably the contract spells out
what the operators will do for the owner, but that's not our problem.

>The URN Framework document says only that
[...]
>but I think that any URN _resolution mechanism_ must be much more
>explicit to be credible

I think you are merging issues that the framework wants to keep
seperate. The framework is based on the notion that we want to
seperate name assignment from resolution, so that different
resolution mechanisms can be used over time for the same namespace,
and so that the same resolution mechanism can be used for different
namespaces (Grandfathering support is the most obvious example of
why we would want to do this, but I think it is a really good idea
in general).

>it is absolutely imperative that any system of naming that is
>intended to be permanent (a prime URN requirements) must explicitly
>deal with the issue of how the _resolution mechanism_ deals with
>organizational change: not just the introduction of new organizations
>but also mergers and divestitures.

I agree with the sentiment but disagree with the details. I think that
proposals for namespaces that are intended to be permanent should
deal with the issues of how organizational change and conflict are
handled in that namespace, and how the *results* of that process can
be made available to resolution systems. The resolution mechanisms
should be told "OK, entity X is now authoritative for portion Y of
namespace Z", and it is their problem how to do the resolution once they
have that knowledge. They should not get involved in the struggles that
lead up to such a decision.


The rest of the message was a reply to Jon Knight's material.
Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"